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(54) System and method for multi-enterprise supply chain optimization 



(57) A method of optimizing multi-enterprise supply 
chain agreements using an electronic option contract in- 
cludes determining at a buyer computer a range of fore- 
casted demand for a product and communicating from 
the buyer computer to a seller computer an offer to enter 
into an option contract for the supply of a product, the 
option contract including an option corresponding to the 



range of forecasted demand. The method further in- 
cludes executing the option contract, updating at the 
buyer computer the forecasted demand, and exercising 
the option in the option contract within the range of fore- 
casted demand based on the updated forecasted de- 
mand. 
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Description 

TECHNICAL FIELD OF THE INVENTION 

[0001 ] The present invention relates to the field of da- 
ta communication and processing, and more particularly 
to a system and method for optimizing multi-enterprise 
supply chain agreements. 

BACKGROUND OF THE INVENTION 

[0002] Various algorithms have been developed to 
help optimize supply chains within an enterprise to avoid 
overstock or undersupply conditions caused by mis- 
matches in supply and demand forecasts. While several 
algorithms have been developed to address supply 
chain optimization within a single enterprise, none have 
addressed supply chain optimization between enterpris- 
es. 

[0003] Conventional approaches to supply chain op- 
timization typically assume that the enterprise can im- 
pose supply chain optimization rules on itself without re- 
gard to the interests of other enterprises. In the context 
of multi-enterprise trading where supply chain optimiza- 
tion rules must be negotiated, the typical approaches 
break down. In the context of multi-enterprise trading, 
therefore, supply/demand mismatches are common. 

SUMMARY OF THE INVENTION 

[0004] In accordance with the present invention, a 
system and method for optimizing multi-enterprise sup- 
ply chains are provided that substantially reduce or elim- 
inate disadvantages or problems associated with previ- 
ously developed supply chain optimization techniques. 
[0005] In one embodiment, a method of optimizing 
multi-enterprise supply chain agreements using an elec- 
tronic option contract comprises determining at a buyer 
computer a range of forecasted demand for a product 
and communicating from the buyer computer to a seller 
computer an offer to enter into an option contract for the 
supply of a product, the option contract including an op- 
tion corresponding to the range of forecasted demand. 
The method further comprises executing the option con- 
tract, updating at the buyer computer the forecasted de- 
mand, and exercising the option in the option contract 
within the range of forecasted demand based on the up- 
dated forecasted demand. 

[0006] In another embodiment, a method of optimiz- 
ing multi-enterprise supply chain agreements using an 
electronic option contract comprises receiving at a seller 
computer terms of an option contract from a buyer com- 
puter, the terms comprising an option corresponding to 
a buyer's range of forecasted demand for a product, 
communicating to the buyer computer an acceptance of 
the terms of the option contract, storing the terms of the 
accepted option contract in a memory accessible to the 
seller computer and enforcing the terms of the option 



contract at the seller computer without user input. 
[0007] Technical advantages of the present invention 
include a system and method for optimizing multi-enter- 
prise supply chains. Through a variety of mechanisms, 
5 the invention increases the profitability of both parties 
to the contract. By implementing one or more option 
terms in the contract, the invention reduces uncertainty 
in each party's forecasts. Providing one or more dimen- 
sions of flexibility to the buyer entity (e.g., options as to 
10 quantity, product, geography, etc.) provides value to the 
buyer entity in allowing it to defer the determination of 
the exact scope of its obligations until a later time, when 
the buyer entity can more accurately determine its ac- 
tual supply needs. — reducing supply/demand mis- 
is matches. The invention provides a mechanism to en- 
sure a win-win situation for both buying and selling par- 
ties by setting an option price to account for the value 
to the buyer entity and the corresponding cost to the sell- 
er entity. In addition, the invention provides an incentive 
for each party to provide the most accurate forecasts 
possible by providing for well-defined penalties for vio- 
lation of the terms of the resulting contract. 
[0008] The use of an option contract provides a sig- 
nificant advantage in on-line negotiations between a 
buyer computer and a seller computer. By using option 
contracts to specify a range or aggregation of potential 
parameter values (such as a range of quantities or prod- 
ucts desired, or a range of delivery locations), the inven- 
tion avoids scores of iterations and transmissions 
across the communication link coupling the buyer and 
seller computers, making on-line negotiations technical- 
ly feasible and very efficient. 

[0009] Other technical advantages are readily appar- 
ent to one of skill in the art from the attached figures, 
description, and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] For a more complete understanding of the 
present invention, and for further features and advan- 
tages thereof, reference is now made to the following 
description taken in conjunction with the accompanying 
drawings, in which: 

FIGURE 1 is a block diagram of an exemplary sys- 
tem for optimizing multi-enterprise supply chains 
constructed according to the present invention; 
FIGURES 2a and 2b are block diagrams of an ex- 
emplary buyer computer and an exemplary seller 
computer, respectively, constructed according to 
the teachings of the present invention; 
FIGURES 3a and 3b are block diagrams of an ex- 
emplary portion of a memory accessible to a buyer 
computer and an exemplary portion of a memory 
accessible to a seller computer, respectively, con- 
structed according to the present invention; 
FIGURE 4 shows exemplary terms of an option con- 
tract executed between a buyer computer and a 
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seller computer according to the present invention; 
FIGURE 5 is a flow chart showing an exemplary 
method of optimizing multi-enterprise supply chain 
agreements using an electronic option contract; 
and 

FIGURE 6 is a flow chart showing another exem- 
plary method of optimizing a multi-enterprise supply 
chain agreement using an electronic option con- 
tract. 

DETAILED DESCRIPTION OF THE INVENTION 

[0011] FIGURE 1 is a block diagram of an exemplary 
multi-enterprise supply chain optimization system 10 
that includes a plurality of buyer computers 20a-20n and 
a plurality of seller computers 40a-40n. In one aspect of 
operation, one or more buyer computers 20 communi- 
cate with one or seller computers 40 to collaborate in 
negotiating the supply by a seller and procurement by 
a buyer of products offered by sellers associated with 
seller computers 40. Buyer computers 20 and seller 
computers 40 cooperate to strive toward an optimum 
supply chain between buyers associated with buyer 
computers 20 and sellers associated with seller com- 
puters 40. Ideally, through an interactive negotiation 
process and contractual monitoring system, system 10 
eliminates mismatches between the buyer's demand 
and the seller's supply, increasing the profitability of 
each enterprise. 

[001 2] Each of buyer computers 20 may execute with 
any of the well-known MS-DOS, PC-DOS, OS-2, 
MAC-OS ) WINDOWSD, UNIX, or other appropriate op- 
erating systems. Each buyer computer 10 may com- 
prise, for example, a desktop computer, a laptop com- 
puter, a personal digital assistant, or any other comput- 
ing or communicating device. Each buyer computer 20 
includes an input device 21 , an output device 22, ran- 
dom access memory (RAM) 24, read-only memory 
(ROM) 26, CD-ROM, hard drive, or other magnetic or 
optical storage media 28 or other appropriate volatile or 
nonvolatile storage and retrieval devices, and a proces- 
sor 30 having a system clock or other suitable timing 
device or software. 

[0013] Input device 21 may comprise, for example, a 
keyboard, mouse, graphics tablet, touch screen, pres- 
sure-sensitive pad, joystick, light pen, microphone, or 
other suitable input device. Output device 22 may com- 
prise, for example, a video display, a printer, a disk drive, 
a plotter, a speaker, or other suitable output device. 
[0014] Items within the dashed lines in FIGURE 1 rep- 
resent exemplary functional operation and data organi- 
zation of the associated components of system 10. For 
example, each buyer computer 20 includes or otherwise 
has access to a memory 32. Memory 32 may comprise 
any of a variety of data structures, arrangements or 
compilations operable to store and facilitate retrieval of 
various information stored locally at buyer computer 20. 
Although memory 32 is depicted as residing within buyer 



computer 20, all or any portion of memory 32 could al- 
ternatively reside at a remote location accessible to buy- 
er computer 20. 

[001 5] Buyer computer 20 executes one or more soft- 

5 ware applications 34. As used in this document, the term 
"software application" refers to a set of instructions, pro- 
cedures, functions, objects, classes, and/or instances, 
and related data adapted for implementation in a suita- 
ble computer language such as C, C++, Java, or any 

10 other appropriate development language. In the illus- 
trated embodiment, software application 34 comprises 
a procurement manager operable to assist buyer com- 
puter 20 in negotiating and executing supply chain con- 
tracts with various seller computers 40. 

is [0016] In this embodiment, each of seller computers 
40 is similar in structure and function to buyer computers 
20. For example, each of seller computers 40 may ex- 
ecute with any of the well-known MS-DOS, PC-DOS, 
OS-2, MAC-OS, WINDOWSD, UNIX, or other appropri- 

20 ate operating systems and may comprise a computing 
or communicating device, such as a desktop computer, 
a laptop computer, or a personal digital assistant. Each 
seller computer 40 includes an input device 41 , an out- 
put device 42, random access memory (RAM) 44, read- 

25 only memory (ROM) 46, CD-ROM, hard drive, or other 
magnetic or optical storage media 48 or other appropri- 
ate volatile or nonvolatile storage and retrieval devices, 
and a processor 50 having a system clock or other suit- 
able timing device or software. In addition, each seller 

30 computer 40 includes or otherwise has access to a 
memory 52. Like buyer computer 20, seller computer 40 
executes one or more software applications 54. In the 
illustrated embodiment, software application 54 com- 
prises a supply manager operable to allow seller com- 

35 puter 40 to negotiate and/or execute supply chain con- 
tracts with various buyer computers 40. 
[0017] Buyer computers 20 and seller computers 40 
communicate with one another using communication 
links 60. In the illustrated embodiment, communication 

40 links 60 comprise communication media suitable to pro- 
vide a connection between buyer computers 20 and/or 
seller computers 40 and a network 12. In this embodi- 
ment, network 1 2 comprises a global computer network, 
such as the Internet. Network 12 may, however include 

45 any suitable wireline, wireless, or combination wireline/ 
wireless system that supports communication between 
network elements using ground-based and/or space- 
based components. For example, network 12 may be 
public switched telephone networks (PSTN), integrated 

50 services digital networks (ISDN), local area networks 
(LAN), wide area networks (WAN), or other communi- 
cation systems or combination of communication sys- 
tems at one or more locations. Communication links 60 
and network 1 2 shown as connecting buyer computers 

55 20 and seller computers 40 may comprise a single net- 
work, or separate networks. 

[0018] Buyer computers 20 and seller computers 40 
include interfaces 38 and 58, respectively, to facilitate 
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connection to communication links 60. These interfaces 
include the appropriate hardware (e.g., modem, net- 
work interface card, etc.) and software (e.g. ; multi-layer 
protocol support, protocol conversion, data processing, 
data modulation, etc.) to communicate using a direct 
connection to a PSTN or ISDN, a connection through a 
LAN, WAN, or global computer network such as the In- 
ternet or any other suitable communication connection 
that allows network elements to communicate using 
communication links 40. 

[0019] Buyer computers 20 and seller computers 40 
also include, browsers 36 and 56, respectively. Brows- 
ers 36 and 56 may comprise any suitable software, 
hardware, or combination thereof, operable to facilitate 
access to — and user interaction with — other network 
elements. In the illustrated embodiment, browsers 36 
and 56 comprises Internet browsers, such as Net- 
scape™ Communicator available from Netscape Com- 
munications Corporation, or Microsoft Explorer™, avail- 
able from Microsoft Corporation. Browsers 36 and 56 
may comprise stand-alone functional elements, as 
shown in the illustrated embodiment. Alternatively, all or 
a portion of the functionality of browsers 36 and 56 could 
be integrated into other components of system 1 0, such 
as interfaces 38 and 58, respectively. 
[0020] Throughout this description, components in 
system 1 0 store, communicate, and access information 
using any format, structure, or arrangement including 
without limitation machine-readable or user-readable 
text and graphics. In a particular embodiment, informa- 
tion exchanged in system 1 0 includes documents orfiles 
written in hypertext mark-up language (HTML), HTML 
Plus, standard generalized mark-up language (SGML), 
virtual reality mark-up language (VRML), extended 
markup language (XML), java objects, or any other ap- 
propriate content development language. Information in 
system 1 0 may also include program code, such as ap- 
plets written in JAVA developed by SUN MICROSYS- 
TEMS, or other appropriate self-executing code. 
[0021] In operation, system 10 facilitates collabora- 
tive negotiations between one or more buyer computers 
20 and one or more seller computers 40 to result in an 
electronic option contract for the supply of particular 
products to buyers utilizing system 10. Either buyer 
computer 20 or seller computer 40 may initiate a nego- 
tiation by transmitting proposed contract terms to the 
other machine. 

[0022] In a particular embodiment, buyer computer 20 
and seller computer40 may negotiate an option contract 
for the supply and purchase of a particular product of- 
fered by a seller associated with setlercomputer 40. The 
resulting option contract contains one or more options, 
which specify obligations of the buyer entity with respect 
to the purchase of a product, and an obligation of the 
seller entity with respect to the supply of that product. 
In a particular embodiment, the option may specify a 
minimum obligation of the buyer in purchasing the prod- 
uct and a maximum obligation of the seller in supplying 



the product. The option, however, could relate to any 
level of obligation between the parties. 
[QG23J The option contraci may further include an op- 
tion price representing a payment of the buyer entity to 
s the seller entity for the value of the option to the buyer 
entity and the cost of the option to the seller entity. In 
addition, the option contract may include penalty provi- 
sions for deviation from the terms of the contract. 
[0024] The use of an option contract provides a sig- 
10 nificant advantage in on-line negotiations between buy- 
er computer 20 and seller computer 40. Without the use 
of an options contract, each computer 20 and 40 of sys- 
tem 10 would have to run an optimization algorithm on 
particular parameter values, obtain a result, and pass 
is the intermediate result to the other machine over net- 
work 12, where that result would be evaluated, modified, 
and retransmitted back to the other machine. This proc- 
ess would continue until an apparently optimum value 
was reached. By using option contracts to specify a 
range or aggregation of potential parameter values 
(such as a range of quantities or products desired, or a 
range of delivery locations), system 1 0 avoids scores of 
iterations and transmissions across network 12. and in- 
stead allows each computer 20, 40 to process an entire 
range of suggested values without transmitting intermit- 
tent suggested values backand forth across network 12. 
[0025] Once the terms of the contract have been ne- 
gotiated, the option contract is executed. In a particular 
embodiment, the terms of the executed option contract 
are stored at the buyer computer 20 and the seller com- 
puter 40. Storing the contract terms facilitate monitoring 
each party's progress in fulfilling of its contractual obli- 
gations. In addition, system 1 0 can enforce the terms of 
the contract by, for example, prohibiting buyer computer 
20 from exercising the buyer entity's options in a manner 
inconsistent with the contract's terms, or by assessing 
penalties for violation of contract's terms. 
[0026] Through the use of electronic option contracts, 
system 10 increases supply chain efficiency by provid- 
ing a comfortable level of certainty in the obligations of 
each party, while maintaining adequate flexibility to 
avoid supply/demand mismatches. 
[0027] FIGURES 2a and 2b are block diagrams of an 
exemplary buyer computer 20 and an exemplary seller 
computer 40, respectively. As discussed above, buyer 
computer 20 includes a memory 32, a procurement 
manager 34, a browser 36, and an interface 38. Simi- 
larly, seller computer 40 includes a memory 52, a supply 
manager 54, a browser 56, and an interface 58. 
[0028] Elements of buyer computer 20 communicate 
with one another over a communication link 110. Com- 
munication link 1 1 0 may comprise any suitable arrange- 
ment of hardware and/or software operable to facilitate 
communication between elements within or peripherally 
coupled to buyer computer 20. For example, communi- 
cation link 110 may comprise a universal serial bus. El- 
ements of seller computer 40 communicate with one an- 
other over a communication link 210. Communication 
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link 21 0 of seller computer 40 is similar in structure and 
function to communication link 110 of buyer computer 
20. 

[0029] In the illustrated embodiment procurement 
manager 34 and supply manager 54 each include a va- 
riety of modules responsible for providing particular 
functionality and processing capabilities. The particular 
number and arrangement of modules shown in FIG- 
URES 2a and 2b are for illustrative purposes only. Other 
and/or additional arrangements, configurations, rela- 
tionships, and processing divisions could be incorporat- 
ed without departing from the scope of the invention. 
[0030] In this embodiment, procurement manager 34 
includes a forecast module 112. Forecast module 112 
operates to provide estimates of the buyer entity's future 
demand based, for example, on historical demand and 
projected market changes. Similarly, supply manager 
54 of seller computer 40 includes a forecast module 21 2. 
Forecast module 21 2 may provide estimates of the sell- 
er's supply capacity, and may also estimate various cus- 
tomers' projected demand based, for example, on a past 
course of dealing with that customer. Buyer computer 
20 and seller computer 40 can be configured to share 
information, such as the assumptions each is using in 
calculating its estimate. By sharing information and al- 
lowing each entity to critique the other's forecasts and 
underlying assumptions, system 10 provides an addi- 
tional advantage of facilitating collaborative forecasting, 
which provides more accurate forecasts resulting in in- 
creased efficiency due to fewer mismatches in supply 
and demand. 

[0031 ] Procurement manager 34 and supply manager 
114 also include negotiation modules 114 and 214, re- 
spectively. Negotiation modules 114 and 214 operate to 
conduct negotiations between buyer computer 20 and 
seller computer 40 with respect to terms of the contract 
being negotiated. In a particular embodiment, negotia- 
tions modules 1 1 4 and 214 can be configured to conduct 
all or a part of the negotiations between buyer computer 
20 and seller computer 40 without requiring user input. 
[0032] To further facilitate negotiations between buyer 
computer 20 and seller computer 40, procurement man- 
ager 34 and supply manager 54 include aggregation 
modules 116 and 216, respectively. Aggregation mod- 
ules 116 and 216 cooperate to align and perform any 
desirable transformation of parameters being negotiat- 
ed. For example, certain contract parameters may be 
expressed as an option, or range of possible values. Ag- 
gregation module 1 1 6 ensures consistency between the 
underlying parameters on which each machine bases 
its computations, so that both parties have a consistent 
understanding of the terms of the resulting contract. 
[0033] Procurement manager 34 and supply manager 
54 may also include option price modules 118 and 218, 
respectively. Option price module 11 8 of buyer computer 
20 estimates the value to the buyer of having flexibility 
to specify the buyer's obligation as a range instead of a 
fixed obligation. Option price module 21 8 of seller com- 



puter 40 estimates the cost to the seller of having a high- 
er potential supply obligation underthe contract than the 
buyer's poieniiai obiigation to purchase. The option 
price ultimately contained in the option contract reflects 

5 a balance between the flexibility gained by the buyer en- 
tity and the cost to the seller entity of facilitating that flex- 
ibility, and may also reflect the relative bargaining 
strength of the parties involved. For example, a domi- 
nant buyer may be in a position to demand an option 

10 without paying any option price, or by paying a lower 
option price. 

[0034] Procurement manger 34 and supply manager 
54 further include execution modules 119 and 219, re- 
spectively. Execution modules 119 and 219 operate to 
15 execute the option contracts and to store the terms of 
the option contracts in memories 32 and 52, respective- 
ly. 

[0035] Procurement manager 34 and supply manager 
54 may also include tracking modules 120 and 220, re- 

20 spectively. Tracking modules 120 and 220 allow buyer 
computer 20 and seller computer 40 to monitor and en- 
force the terms of any currently pending contract. 
[0036] Memory 32 of buyer computer 20 includes a 
variety of files. In the illustrated embodiment, memory 

25 32 includes a buyer information file 1 30, which can store 
various information relating to the buyer entity's busi- 
ness, as well as its historical and projected supply 
needs. Forecast module 112 and/or aggregation mod- 
ule 116 may access buyer information file 130 to obtain 

30 information helpful in forecasting supply needs and per- 
forming any necessary aggregate transformation during 
negotiations with seller computer 40. 
[0037] Memory 32 further includes a contract informa- 
tion file 1 32, which stores information relating to current- 

35 |y pending contracts. Tracking module 120 can access 
contract information file 132, to observe and/or modify 
information associated with currently pending contracts 
as the contracts progress. Memory 32 may further in- 
clude negotiation information file 134, which includes 

40 various information useful in negotiating the terms of a 
contract. For example, negotiation information file 134 
may include historical price lists, previous discounts of- 
fered by the seller entity or competitors of the seller en- 
tity, acceptable delivery schedules, and other informa- 

45 tion relating to previously negotiated contracts. Negoti- 
ation module 114 may access negotiation information 
file 134 in determining whether to accept suggested 
contractual terms, counter-offer, or flag a particular is- 
sue as a problem requiring user attention. 

so [0038] Memory 52 of seller computer 40 contains sim- 
ilar information files. For example, memory 52 includes 
a seller information file 230 containing various informa- 
tion relating to the seller entity's business, as well as its 
historical and projected ability to meet demand needs. 

55 Forecast module 212 and/or aggregation module 216 
may access seller information file 230 to obtain informa- 
tion helpful in forecasting the seller entity's inventory 
and ability to meet projected demand needs, as well as 
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to perform any necessary aggregate transformation dur- 
ing negotiations with seller computer 40. 
[0039] Memory 52 further includes a contract informa- 
tion file 232, which stores information relating to current- 
ly pending contracts. Tracking module 220 can access 
contract information file 232, to observe and/or modify 
information associated with currently pending contracts 
as the contracts progress. Memory 32 may further in- 
clude negotiation information file 234, which includes 
various information useful in negotiating the terms of a 
contract. For example, negotiation information file 234 
may include price lists previously given to particular buy- 
ers, discounts available to particular buyers, acceptable 
delivery schedules, and other information relating to 
previously negotiated contracts. Negotiation module 
214 may access negotiation information file 234 in de- 
termining whether to accept suggested contractual 
terms, counter-offer, or flag a particular issue as a prob- 
lem requiring user attention. 

[0040] In operation, forecast module 112 of buyer 
computer 20 may initially approximate its supply needs 
by applying current and/or historical supply data to var- 
ious supply forecasting and optimization models to yield 
approximate supply needs. These supply needs may be 
expressed in terms of, for example, a product type, a 
quantity of product and/or a geographical region. 
[0041] Known information may suggest that it is ap- 
propriate to rely on the accuracy of one or more of the 
approximations. For example, it may be known that an 
enterprise in particular geographical region may cur- 
rently be out of stock of a particular product; it may fur- 
ther be known that the enterprise has a need for that 
product by a particular date. In that case, the particular 
product, geographic region of the enterprise, and deliv- 
ery date can be specified with confidence. 
[0042] In other cases, for various reasons, such as 
uncertainty in market conditions, the approximations 
yielded by the forecasting and optimization models may 
be suspect or uncertain. Continuing with the previous 
example, while it may be known that a particular enter- 
prise in a particular geographical location will require 
some level of a particular product by a specified date, 
the exact quantity required may not be ascertainable 
with any certainty. Forecast module 112 may account 
for this uncertainty by specifying the quantity parameter 
as a range of potential values, or as an option to pur- 
chase a quantity between a minimum specified quantity 
and a maximum specified quantity. 
[0043] Buyer computer 20 may, through negotiation 
module 114, derive suggested contractual terms, such 
as the price of the product, the execution date of the 
contract, an exercise date or range of exercise dates for 
any option ranges identified by forecast module 112, 
and/or any other term desired to be included in a supply 
contract. Negotiations module 114 may consult, for ex- 
ample, buyer information file 130 and/or negotiation in- 
formation file 134 in deriving the suggested contractual 
terms. 



[0044] Buyer computer 20 communicates the sug- 
gested contractual terms — including forecasted supply 
requirements expressed as a range or an option — to 
seller computer 40 associated with the seller supplying 

5 the desired product or products. Negotiation modules 
1 1 4 and 21 4 of buyer computer 20 and seller computer 
40, respectively, begin with the suggested contract 
terms and negotiate the terms of an option contract for 
the supply of the desired product(s). Prior to or during 

10 the negotiation process, aggregation modules 116 and 
21 6 may perform any necessary or desired aggregation 
alignment and/or transformation. Aggregation modules 
1 1 6 and 216 may access buyer information file 1 1 2 and 
seller information file 212 to determine a common ag- 

15 gregation of parameters to be implemented in the con- 
tract. 

[0045] FIGURES 3a and 3b are block diagrams of an 
exemplary portion of memory 32 associated with buyer 
computer 32 and of memory 52 associated with seller 

20 computer 40, respectively. In the illustrated embodi- 
ment, buyer information file 130 includes product infor- 
mation 310, which comprises a compilation of various 
information related to the products that the buyer entity 
using buyer computer 20 uses. In this example, product 

25 information 310 is arranged by product type 312; each 
product type 31 2 is further arranged by vendor 31 4, and 
then by product model 316-322. 
[0046] Seller information file 230 of memory 52 also 
includes product information 410, which is similar to 

30 product information 31 0 stored in memory 32. However, 
product information 41 0 stored in memory 52 comprises 
a slightly different aggregation than product information 
31 0 stored in memory 32. To ensure that buyer compu- 
ter 20 and seller computer 40 are able to negotiate con- 

35 sistent contractual terms, it may be desirable to use ag- 
gregation modules 1 1 6 and 21 6 to determine a common 
aggregation of parameters. In this case, buyer computer 
20 arranges its product information 31 0 by product type, 
vendor, and model number; seller computer 40 arranges 

40 its product information 41 0 by product type, product sub- 
type 412, product application 41 4, and model 41 6-428. 
To provide a consistent aggregation, aggregation mod- 
ule 1 1 6 of buyer computer 20 may temporarily reaggre- 
gate buyer product information 31 0 to be consistent with 

45 seller product information 410. For example, aggrega- 
tion module 1 1 6 may disaggregate the buyer product in- 
formation 310 down to its most granular level (in this 
case, model numbers 316-322) and then build an ag- 
gregation to match that of seller product information 

50 410. 

[0047] As a particular example, buyer computer 20 
may suggest a contract option comprising an offer to 
purchase a quantity of "desktop computers." The aggre- 
gation of "desktop computers" would commit the buyer 
55 entity to purchase some number of the seller entity's 
desktop computers, but give the buyer entity flexibility 
in selecting which particular model or models to pur- 
chase until a later date. Aggregation modules 116 and 
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216 : therefore, facilitate specification of ranges of obli- 
gations that each party is willing to undertake. The pa- 
rameters expressed as a range of possible values may 
ultimately be incorporated into the option contract in the 
form of an option. 

[0048] The options ultimately incorporated into the 
option contract specify a range of values which repre- 
sents an obligation on the buyer entity to purchase the 
product and an obligation on the seller entity to supply 
the product. Although the previous example suggested 
an option as to the particular product models selected, 
similar options could be created that specify for exam- 
ple, a range of quantity of a particular product desired, 
a range of geographical regions to be served, and/or 
various other attributes associated with the buyer enti- 
ty's supply needs. Resulting contracts could have one 
or several dimensions of options. For example, a result- 
ing option contract could specify the delivery location 
(region), but may create an option as to the exact prod- 
uct to be delivered and the exact quantity demanded. 
Any combination of option as to region ; product, quan- 
tity, or other appropriate parameter could be implement- 
ed without departing from the scope of the invention. 
[0049] Facilitating negotiation of an option contract 
provides an advantage to the buyer enterprise in allow- 
ing the buyer enterprise to defer the determination of the 
exact scope of its obligations until a later time, when the 
buyer entity can more accurately determine its actual 
supply needs. This flexibility, however, comes at a cost 
to the seller entity, who must be prepared to meet the 
maximum contractual obligation even if the buyer entity 
ultimately chooses a narrower contractual scope. The 
seller entity may, therefore, desire compensation for this 
added cost in the form of an option price. 
[0050] As part of the negotiation process, buyer com- 
puter 20 and seller computer 40 may determine an op- 
tion price based, for example, on the value of the option 
to the buyer entity and the cost of the option to the seller 
entity. Generally, the greater the flexibility offered to the 
buyer entity, the higher the cost to the seller entity, and 
the higher the option price. In determining the option 
price, option price module 118 of buyer computer 20 
may determine the value of a particular option range to 
the buyer entity. Likewise, option price module 218 of 
seller computer 40 may determine the seller entity's cost 
of providing that option. Through an iterative process, 
buyer computer 20 and seller computer 40 can deter- 
mine an option range associated with an option price 
acceptable to both the buyer and the seller. 
[0051] Continuing with the negotiation process, nego- 
tiation modules 1 1 4 and 21 4 may access negotiation in- 
formation files 134 and 234 to ascertain acceptable 
compromises in parametervalues, such as, price, quan- 
tity, delivery locations, and/or delivery timing. Negotia- 
tion information files 1 34 and 234 comprise information, 
such as, price lists 342; previous discounts offered 344, 
442; and other previous contractual terms 346, 444. Ne- 
gotiation modules 114 and 214 may be programmed to 



accept proposed contract terms provided that they fall 
in a given range or bear a particular relation to previously 
negotiated ierms. in addition, negotiation modules 114 
and 214 may be programmed to flag certain contractual 
5 terms as problem issues, which require user interven- 
tion and negotiation. 

[0052] Once the terms of the option contract are ne- 
gotiated, execution modules 1 1 9 and 21 9 of buyer com- 
puter 20 and seller computer 40 and/or the users of 
10 those machines execute the option contract. In the illus- 
trated embodiment, both buyer computer 20 and seller 
computer 40 store the terms of the option contract in 
memories 32 and 52, respectively. Referring again to 
FIGURES 3a and 3b, the negotiated contractual terms 
15 are stored in contract information files 132 and 232 of 
buyer computer 20 and seller computer 40, respectively. 
[0053] In the illustrated embodiment, contract infor- 
mation files 132 and 232 store information relating to 
each contract 332 and 432, respectively. Among the in- 
formation stored is the terms of the contract 334 and 
434, and tracking information 336 and 436. Tracking 
modules 120 and 220 of buyer computer 20 and seller 
computer 220, respectively, may access contract infor- 
mation files 132 and 232, respectively, to monitor and 
enforce the performance of the negotiated contracts. 
[0054] FIGURE 4 shows an example of terms of an 
option contract 500 executed by buyer computer 20 and 
seller computer 40. Among the terms of the option con- 
tract is an identification of: the buying enterprise 510, 
the selling enterprise 512. the execution date 514, the 
delivery date 516, the product to be delivered 518, the 
delivery location 520, the sales price 522, and a penalty 
provision 524 to be exercised in the event of a violation 
of the terms of option contract 500. 
[0055] Also among the terms of contract 500 is an in- 
dication of the contract type 502. In this particular ex- 
ample, buyer computer 20 and seller computer 40 have 
negotiated an incrementally exercised quantity options 
contract. The optional term in this contract is the precise 
quantity that the buyer entity will be obligated to pur- 
chase and that the seller entity will be obligated to sup- 
ply. Contract terms 526 and 526 specify the upper and 
lower limits, respectively, of the quantity option 530. Ac- 
cording to this contract, the buyer entity will ultimately 
be responsible for purchasing at least 8,000 units; the 
seller will be responsible for supplying up to 10,000 
units. For this option, the parties have negotiated an op- 
tion price 532 of$5,000. 

[0056] Option contract 500 also specifies a range of 
exercise dates 534 specifying the earliest possible date 
536 that the buyer entity can exercise its option under 
contract 500, and the latest possible date 538 by which 
the buyer entity must exercise its option under contract 
500. This particular contract is an incrementally exer- 
cised contract. Under this type of contract, beginning at 
the exercise start period 536, the buyer entity may in- 
crementally place several individual orders for the de- 
sired product over the course of the exercise period 534. 
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The seller entity has agreed to supply the cumulative 
total of all orders placed during the exercise period. This 
type of contract is particularly advantageous tc the buy- 
er entity, as it allows the buyer entity to estimate a flex- 
ible range of quantity over a range of time. The buyer 
entity can then place purchase orders according to its 
actual demand during the exercise period, greatly re- 
ducing or eliminating the chances of supply demand 
mismatches. 

[0057] In processing this type of contract, seller com- 
puter 40 accepts buyer computer 20's orders after the 
beginning exercise date 536. Seller computer 40 re- 
ceives purchase orders as long as the cumulative 
amount of product ordered does not exceed the upper 
quantity limit 528 specified in contract 500 and until the 
exercise end date 538. Seller computer could, of course, 
be programmed to accept purchase orders specifying a 
quantity greater than upper quantity limit 528 or orders 
received before the beginning exercise date 536 or after 
the exercise end date 538. Under the terms of contract 
500 : however, seller computer 40 is not required to ac- 
cept such orders. 

[0058] Seller computer 40 stores a record of each pur- 
chase order received and, after expiration of the exer- 
cise period 534, facilitates delivery of a cumulative total 
order not exceeding upper quantity limit 528. If buyer 
computer 20 fails to reach the lower quantity limit 526 
by the end of the exercise period 538, seller computer 
40 may impose penalty 524 in an amount commensu- 
rate with the buying entity's shortfall in purchase orders. 
By the same token, if the seller entity fails to deliver a 
valid quantity of product, or delivers the product too late 
or to the wrong destination, buyer computer 20 may im- 
pose penalty 524 for the seller entity's violation. 
[0059] System 1 0 provides significant advantages in 
optimizing supply chains in a multi-enterprise trading 
environment. Through a variety of mechanisms, system 
10 increases the profitability of both parties to the con- 
tract. By using one or more option terms in the contract, 
system 1 0 reduces uncertainty in each party's forecasts. 
Providing one or more dimensions of flexibility to the 
buyer entity (e.g., options as to quantity, product, geog- 
raphy, etc.) provides value to the buyer entity in allowing 
it to later select optimum exercise values for the option 
parameters — reducing supply/demand mismatches. 
System 10 provides a mechanism to ensure a win-win 
situation for both parties by setting an option price to 
account for the value to the buyer entity and the corre- 
sponding cost to the seller entity. In addition, providing 
for well-defined penalties for violation of the terms of the 
resulting contract provides an incentive for each party 
to provide the most accurate forecasts possible. 
[0060] FIGU RE 5 is a flow chart showing an exempla- 
ry method 600 of optimizing multi-enterprise supply 
chain agreements using an electronic option contract. 
In this particular example, the method 600 describes a 
process for implementing an electronic incrementally 
exercised option contract 500 (FIGURE 4). The method 



begins at step 605 where buyercomputer20 determines 
a range of forecasted demand. For example, forecast 
module 112 of buyer computer 20 initially approximates 
the buyer's demand by applying current and/or historical 

5 data to various demand forecasting and optimization 
models to yield an approximate forecasted demand. 
Based on, for example, statistical models identifying his- 
torical or estimated errors in the forecasted demand, 
forecasting module 112 identifies a range of forecasted 

10 demand which accounts for these potential errors. 
[0061] Computer 20 also determines an option price 
associated with the range of forecasted demand at step 
610. For example, option price module 118 may deter- 
mine the value of the flexibility gained by the range of 

15 forecasted demand (as opposed to a fixed forecasted 
demand) and assign an option price corresponding to 
that value. At some point, preferably prior to negotiating 
with seller computer 40, buyer computer 20 may contact 
seller computer 40 and perform aggregation alignment 

20 and translation at step 615. For example, aggregation 
module 116 of buyer computer 20 may communicate 
with aggregation module 216 of seller computer 40 to 
establish a common aggregation of contract terms. Buy- 
er computer 20 communicates an offer to enter into an 

25 option contract to seller computer 40 at step 620. The 
offer to enter into an option contract includes an option 
corresponding to the range of forecasted demand iden- 
tified by buyer computer 20, and may also include a pro- 
posed option price. 

30 [0062] Typically, buyer computer 20 will receive alter- 
nate proposed contract terms from seller computer 40 
at step 625. Negotiation module 114 may analyze the 
alternate proposed contract terms by accessing memo- 
ry 32 to determine a range of acceptable contract terms 

35 at step 630, and determining at step 635 whether the 
alternate proposed contract terms are within the range 
of acceptable contract terms retrieved from memory 32. 
If negotiation module 114 determines at step 640 that 
the alternate proposed terms are within the acceptable 

40 range retrieved from memory 32, negotiation module 
114 may accept the alternate proposed terms without 
user input at step 650. In the event that negotiation mod- 
ule 114 determines at step 640 that the alternate pro- 
posed terms are not within the acceptable range re- 

45 trieved from memory 32, negotiation module 114 may 
identify the alternate proposed contract term or terms 
as requiring user input prior to acceptance at step 645. 
A user of buyer computer 20 may intervene to negotiate 
the nonaccepted proposed term, and execution module 

50 119 may execute the contract at step 655. In addition, 
execution module 119 may store the terms of the exe- 
cuted contract in contract information file 1 32 of memory 
32, 

[0063] In this particular example, the executed con- 
55 tract 500 (see FIGURE 4) is an incrementally exercised 
option contract. Tracking module 1 20 determines at step 
660 whether the exercise period 534 has begun. Any- 
time after exercise period 534 has begun, tracking mod- 
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ule 120 may initiate, or act in response to a user input 
requesting an update of the buyer's forecasted demand. 
Forecasting module 1 1 2 updates ihe buyers forecasted 
demand to determine the buyer's current demand 
needs. Exercise module 121 communicates a request 
to seller computer 40 to exercise the option in the con- 
tract according to the updated forecasted demand at 
step 670. Tracking module 120 stores the value of the 
updated forecasted demand in contract information file 
132 of memory 32. 

[0064] Tracking module 120 next determines at step 
675 whether the exercise of the option satisfies the buy- 
er's minimum obligation, in this case specified by lower 
quantity limit 526 of contract 500. If the buyer's minimum 
obligation has not been met, tracking module 120 de- 
termines at step 680 whether the exercise period has 
ended. If the exercise period has ended, and the buyer's 
minimum obligation has not been met, tracking module 
120 determines a penalty at step 685 for the buyer's 
shortfall in its minimum obligation. If, however, tracking 
module 120 determines at step 680 that time remains 
in the exercise period, tracking module 120 awaits an- 
other update to the buyer's forecasted demand at step 
665. 

[0065] Even where the buyer's minimum obligation 
has been met at step 675, the terms of contract 500 al- 
low buyer computer 20 to place further purchase orders 
prior to the expiration of the exercise period. For exam- 
ple, procurement manager 34 may determine at step 
690 that despite the buyer's minimum obligation being 
met. the exercise period has not ended. If buyer com- 
puter 20 received an indication, either through user input 
or through information stored in memory 32, that the 
buyer entity desires more product at step 695, procure- 
ment manager may communicate another updated fore- 
cast demand at step 665 requesting additional product. 
In a particular embodiment, procurement manager 34 
may be programmed to refuse to communicate another 
updated forecast demand if it determines at 698 that the 
seller's maximum obligation has been met. For exam- 
ple, contract 500 specifies an upper quantity limit 528 of 
ten thousand units. If buyer computer 20 has already 
requested ten thousand units, procurement manager 34 
can be programmed to disallow further requests to seller 
computer 40. 

[0066] FIGURE 6 is a flow chart showing an exempla- 
ry method of optimizing a multi-enterprise supply chain 
agreement. Method 700 begins at step 705 where sup- 
ply manager 54 of seller computer 40 receives proposed 
terms of an option contract 500 from buyer computer 20. 
Aggregation module 21 6 may align and translate the ag- 
gregation of parameters in option contract 500 at step 
710. 

[0067] Typically, forecast module 212 will determine 
a range of forecasted supply capacity at step 715 and 
an option price associated with that range of forecasted 
supply capacity at step 720. Based on these calcula- 
tions, negotiation module 214 of supply manager 54 



may determine at step 725 whether the contract terms 
proposed by buyer computer 20 are acceptable. In ad- 
dition, or in the alternative, negotiation module 214 may 
consult negotiation information file 234 to determine 

5 whether the proposed contract terms are acceptable. If 
the proposed contract terms are found to be acceptable 
at step 725, execution module 219 executes the option 
contract at step 740. If, however, negotiation module 
214 determines at step 725 that the proposed contract 

10 terms are not acceptable, negotiation module 214 may 
communicate alternate proposed contract terms to buy- 
er computer 20 at step 730 and negotiate the ultimate 
terms of the contract at step 735. The negotiating step 
735 may include comparing proposed contract terms to 

15 a range of acceptable terms stored in negotiation file 
234, and identifying particular terms as requiring user 
input prior to acceptance. 

[0068] Execution module 219 stores the terms of the 
executed contract in memory 52 at step 745. This ex- 

20 ample, like the one described with respect to FIGURE 
5, addresses the execution of an incrementally exer- 
cised option contract 500 (see FIGURE 4). Upon receiv- 
ing a request from buyer computer 20 to exercise an 
option in the contract at step 750, supply manager 54 

25 accesses memory 52 to determine the terms of the op- 
tion contract at step 755. Supply manager 54 deter- 
mines at step 760 whether exercise period 534 has be- 
gun. If supply manager 54 determines at step 760 that 
exercise period 534 has not begun, supply manager 54 

30 notifies buyer computer 20 at step 765 that its request 
is improper, in this case because it is premature. Of 
course, supply manager 54 can be programmed to ac- 
cept premature purchase orders. 
[0069] If supply manager 54 determines at step 760 

35 that exercise period 534 has begun, it determines at 
step 770 whether the request exceeds the maximum 
seller obligation. In this case, the option 530 in contract 
500 is a quantity option specifying a lower quantity limit 
526 and an upper quantity limit 528. Lower quantity limit 

40 526 specifies the minimum obligation of the buyer in pur- 
chasing the specified product, and upper quantity limit 
528 specifies the maximum obligation of the seller in 
supplyingthat product. If supply manager 54 determines 
at 770 that the exercise request from buyer computer 

45 20 exceeds the maximum seller obligation, in this case 
upper quantity limit 528, supply manager 54 notifies 
buyer computer 20 that its request is improper at step 
765. Of course, supply manager 54 could be pro- 
grammed to accept exercise requests that exceed the 

50 maximum seller obligation, for example, those exceed- 
ing the maximum seller obligation by a predetermined 
amount. 

[0070] If supply manager 54 determines at step 770 
that the exercise request received from buyer computer 
55 20 does not exceed the maximum seller obligation, it 
stores the exercise request at step 775 in contract infor- 
mation file 232 of memory 52. Supply manager 54 de- 
termines at step 780 whether the exercise period 534 
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has ended. For example : supply manager 54 may com- 
pare a current date (obtained, for example, from the sys- 
tem clock of seller computer 40) with exercise period 
end date 538. If supply manager 54 determines at step 
780 that the exercise period 534 has not ended, it may 
receive another exercise request at step 785 from buyer 
computer 20 and process that request as described 
above. 

[0071] If supply manager 54 determines at step 780 
that exercise period 534 has ended, it determines at 
step 790 whether the minimum obligation 526 of the 
buyer has been met. In this case, the minimum buyer 
obligation 526 is a requirement that the buyer purchased 
a minimum quantity of product. If supply manager 54 
determines at step 790 that the buyer's minimum obli- 
gation has not been met, it determines a penalty at step 
795 for the buyer's short fall. In this example, contract 
500 contains a penalty provision 524 specifying a pen- 
alty of one dollar per unit of quantity violation. Tracking 
module 220 accesses contract information file 232 to 
identify this contract provision, compare it to the quantity 
exercised by buyer computer 20, and calculate a result- 
ing penalty. 

[0072] Supply manager 54 facilitates satisfaction of 
the seller's obligation at step 800. For example, supply 
manager 54 can be programmed to automatically 
schedule delivery of the exercised quantity of product if 
that exercised quantity is at least equal to the lower 
quantity limit 526 and not more than the upper quantity 
limit 528. Of course, supply manager 54 can also be pro- 
grammed to accommodate deliver of non-conforming 
quantity requests. 

[0073] Although the present invention has been de- 
scribed in several embodiments, a myriad of changes, 
variations, alterations, transformations, and modifica- 
tions may be suggested to one skilled in the art, and it 
is intended that the present invention encompass such 
changes, variations, alterations, transformations, and 
modifications as fall within the spirit and scope of the 
appended claims. 

Claims 

1 . A method for optimizing a multi-enterprise supply- 
chain agreement using an electronic option con- 
tract, the method comprising: 

determining, at a buyer computer system asso- 
ciated with a buyer, a forecasted buyer demand 
range for a product; 

communicating, from the buyer computer sys- 
tem to a seller computer system associated 
with a seller, a proposed option contract for a 
supply of the product comprising a proposed 
option based on the forecasted buyer demand 
range; 

executing an option contract that comprises an 



option based at least in part on the proposed 
option; 

receiving, at the buyer computer system, an in- 
dication of current buyer demand for the prod- 

5 uct; and 

communicating, from the buyer computer sys- 
tem to the seller computer system, a request to 
exercise at least a portion of the option, the re- 
quest being based at least in part on the indi- 

10 cated current buyer demand. 

2. The method of Claim 1 , comprising: 

determining whether the indicated current buy- 
15 er demand exceeds a maximum option quantity 

specified in the option contract; and 
communicating the request only if the indicated 
current buyer demand does not exceed the 
maximum option quantity specified in the option 
20 contract. 

3. The method of Claim 1, further comprising, at the 
buyer computer system: 

25 monitoring an exercised portion of the option; 

comparing the exercised portion of the option 
with a minimum option quantity specified in the 
option contract to determine whether a buyer 
obligation under the option contract has been 
30 met; 

determining whether an option period specified 
in the option contract has ended; and 
if the buyer obligation has not been met and the 
option period has ended, determining an appli- 
es cable buyer penalty based at least in part on a 
penalty specified in the option contract, 

4. The method of Claim 1 , wherein the option compris- 
es one or more ranges of parameters that are each 

40 selected from a group consisting of: 

a minimum quantity of the product that the buy- 
er is obligated to purchase and a maximum 
quantity of the product that the seller is obligat- 
es ed to supply; 

a minimum number of product types that the 
buyer is obligated to purchase and a maximum 
number of product types that the seller is obli- 
gated to supply; and 
50 a minimum number and a maximum number of 

locations where the product must be delivered. 

5. The method of Claim 1 , wherein the option contract 
comprises an exercise period that comprises a pe- 

55 nod of time after the execution of the option contract 
during which the buyer must exercise the option. 

6. The method of Claim 1 , further comprising: 
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receiving, at the buyer computer system and 
from the seder computer system, an alternative 
buyer demand range that is different from the 
forecasted buyer demand range; and 
accepting the alternative buyer demand range 5 
as a term of the option contract. 

7. The method of Claim 1 . further comprising: 

receiving, at the buyer computer system and 10 
from the seller computer system, a proposed 
contract term from the seller computer system; 
accessing a memory comprising a range of ac- 
ceptable contract terms; 

determining, at the buyer computer system, '5 
whether the proposed contract term is within 
the range of acceptable contract terms; 
if the proposed contract term is within the range 
of acceptable contract terms, accepting the 
proposed contract term without user input; and 20 
if the proposed contract term is outside the 
range of acceptable contract terms, identifying 
the proposed contract term as requiring user in- 
put. 

25 

8. The method of Claim 1 , further comprising: 

determining, at the buyer computer system, a 
proposed option price comprising a value of the 
option to the buyer; 30 
communicating the proposed option price to the 
seller computer system; and 
negotiating with the seller computer system an 
agreed option price based on the value of the 
option to the buyer and a cost of the option to 35 
the seller. 

9. The method of Claim 8, wherein negotiating an 
agreed option price comprises: 

40 

receiving, at the buyer computer system and 
from the seller computer system, an alternative 
buyer demand range that is different from the 11 
forecasted buyer demand range; 
determining, at the buyer computer system, a 45 
modified proposed option price based on the al- 
ternative buyer demand range; and 
communicating the modified proposed option 
price to the seller computer system. 

50 

10. A method for optimizing a multi-enterprise supply 
chain agreement using an electronic option con- 
tract, the method comprising: 

receiving, at a seller computer system associ- 55 
ated with a seller and from a buyer computer 
system associated with a buyer, a proposed op- 
tion contract for a supply of a product compris- 



ing a proposed option based on a forecasted 
buyer demand range for a product; 
executing an option contract that comprises an 
option based at least in part on the proposed 
option; 

storing, at the seller computer system, one or 
more terms of the option contract; 
receiving, at the seller computer system and 
from the buyer computer system, a request to 
exercise at least a portion of the option, the re- 
quest being based at least in part on an indica- 
tion of current buyer demand for the product; 
at the seller computer system, in response to 
receiving the request: 

accessing the stored terms of the option 
contract; and 

using the stored terms of the option con- 
tract: 

determining whether an option period 
specified in the option contract has be- 
gun; 

if the option period has not yet begun, 
notifying the buyer computer system 
that the request is premature; and 
if the option period has begun: 

determining whether the request 
specifies a request quantity that 
exceeds a maximum option quan- 
tity specified in the option con- 
tract; 

if the request quantity exceeds the 
maximum option quantity, notify- 
ing the buyer computer system 
that the request is improper; and 
if the request quantity does not ex- 
ceed the maximum option quanti- 
ty, storing the request for seller 
compliance. 

The method of Claim 1 0, further comprising, at the 
seller computer system: 

monitoring an exercised portion of the option; 
comparing the exercised portion of the option 
with a minimum option quantity specified in the 
option contract to determine whether a buyer 
obligation under the option contract has been 
met; 

determining whether an option period specified 
in the option contract has ended; and 
if the buyer obligation has not been met and the 
option period has ended, determining an appli- 
cable buyer penalty based at least in part on a 
penalty specified in the option contract. 
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12. The method of Claim 10, wherein the option com- 
prises one or more ranges of parameters that are 
each selected from a group consisting of; 

a minimum quantity of the product that the buy- 5 
er is obligated to purchase and a maximum 
quantity of the product that the seller is obligat- 
ed to supply; 

a minimum number of product types that the 
buyer is obligated to purchase and a maximum 10 
number of product types that the seller is obli- 
gated to supply; and 

a minimum number and a maximum number of 
locations where the product must be delivered. 

15 

13. The method of Claim 12, wherein: 

the request specifies a first quantity of product 
desired; and 

the method further comprises; 20 

storing the request at the seller computer 
system; 

receiving, at the seller computer system 
and from the buyer computer system, a 25 
subsequent request to exercise at least a 
portion of the option, the subsequent re- 
quest specifying a second quantity of prod- 
uct desired; 

determining, at the seller computer sys- 30 
tern, whether the exercise period has ex- 
pired; and 

if the exercise period has not expired, stor- 
ing the subsequent request at the seller 
computer system. 35 

14. A procurement manager executable at a buyer 
computer system associated with a buyer, the pro- 
curement manager comprising: 

40 

a forecast module operable to determine a fore- 
casted buyer demand range for a product; 
a negotiation module operable to: 

communicate, to a seller computer system 45 
associated with a seller a proposed option 
contract for a supply of the product com- 
prising a first proposed option based on the 
forecasted buyer demand range; 
receive from the seller computer system an 50 
alternative buyer demand range that is dif- 
ferent from the forecasted buyer demand 
range; 

communicate the alternative buyer de- 
mand range to the forecast module; and 55 
receive from the forecast module a com- 
promise buyer demand range; 



an execution module operable to execute an 
option contract based at least in part on the 
compromise buyer demand range; and 
an option-exercise module operable to: 

receive from the forecast module an indi- 
cation of current buyer demand for the 
product within the compromise buyer de- 
mand range; and 

communicate, to the seller computer sys- 
tem, a request to exercise at least a portion 
of the option, the request being based at 
least in part on the indicated current buyer 
demand. 

1 5. The procurement manager of Claim 1 4, wherein the 
option comprises one or more ranges of parameters 
that are each selected from a group consisting of: 

a minimum quantity of the product that the buy- 
er is obligated to purchase and a maximum 
quantity of the product that the seller is obligat- 
ed to supply; 

a minimum number of product types that the 
buyer is obligated to purchase and a maximum 
number of product types that the seller is obli- 
gated to supply; and 

a minimum number and a maximum number of 
locations where the product must be delivered. 

16. The procurement manager of Claim 14, further 
comprising a tracking module operable to: 

monitor an exercised portion of the option; 
compare the exercised portion of the option 
with a minimum option quantity specified in the 
option contract to determine whether a buyer 
obligation under the option contract has been 
met; 

determine whether an option period specified 
in the option contract has ended; and 
if the buyer obligation has not been met and the 
option period has ended, determine an applica- 
ble buyer penalty based at least in part on a 
penalty specified in the option contract. 

1 7. The procurement managerof Claim 1 4, wherein the 
negotiation module is further operable to; 

receive a proposed contract term from the sell- 
er computer system; 

access a memory comprising a range of ac- 
ceptable contract terms; 
determine whether the proposed contract term 
is within the range of acceptable contract terms; 
if the proposed contract term is within the range 
of acceptable contract terms, accept the pro- 
posed contract term without user input; and 
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if the proposed contract term is outside the 
range of acceptable contract terms, identify the 
proposed contract term as a term requiring user 
input. 

18. The procurement manager of Claim 14, further 
comprising an aggregation module operable to: 

compare a buyer aggregation of parameters 
with a seller aggregation of the parameters; and 
modify at least one of the buyer or seller aggre- 
gations to more or less conform with a common 
aggregation of parameters. 

19. The procurement manager of Claim 14: 

further comprising an option price module op- 
erable to: 

determine a proposed option price com- 
prising a value of the option to the buyer; 
and 

communicate the proposed option price to 
the seller computer system; 

the negotiation module being operable to nego- 
tiate with the seller computer system an agreed 
option price based on the value of the option to 
the buyer and a cost of the option to the seller. 

20. A supply manager executable at a seller computer 
system associated with a seller, the supply manag- 
er comprising: 

a forecast module operable to determine a fore- 
casted supply capacity range for a product; 
a negotiation module operable to receive, from 
a buyer computer system associated with a 
buyer, a proposed option contract for a supply 
of the product comprising a proposed option 
based on a forecasted buyer demand range for 
the product; 

an execution module operable to: 



contract; and 

using the stored terms of the option 
contract: 

5 determine whether an option peri- 

od specified in the option contract 
has begun; 

if the option period has not yet be- 
gun, notify the buyer computer 
10 system that the request is prema- 

ture; and 

if the option period has begun: 

determine whether the re- 
's quest specifies a request 

quantity that exceeds a maxi- 
mum option quantity specified 
in the option contract; 
if the request quantity ex- 
20 ceeds the maximum option 

quantity, notify the buyer com- 
puter system that the request 
is improper; and 
if the request quantity does 
25 not exceed the maximum op- 

tion quantity, storing the re- 
quest at the seller computer 
system for compliance. 

30 21. The supply manager of Claim 20, wherein the op- 
tion comprises one or more ranges of parameters 
that are each selected from a group consisting of: 



35 



40 



a minimum quantity of the product that the buy- 
er is obligated to purchase and a maximum 
quantity of the product that the seller is obligat- 
ed to supply; 

a minimum number of product types that the 
buyer is obligated to purchase and a maximum 
number of product types that the seller is obli- 
gated to supply; and 

a minimum number and a maximum number of 
locations where the product must be delivered. 



execute an option contract that comprises 45 
an option based at least in part on the pro- 
posed option; and 

store one or more terms of the option con- 
tract; and 

50 

a tracking module operable to: 

receive, from the buyer computer system, 
a request to exercise at least a portion of 
the option; and 55 
in response to receiving the request: 

access the stored terms of the option 



22. The supply manager of Claim 20, further comprising 
a tracking module operable to: 

monitor an exercised portion of the option; 
compare the exercised portion of the option 
with a minimum option quantity specified in the 
option contract to determine whether a buyer 
obligation under the option contract has been 
met; 

determine whether an option period specified 
in the option contract has ended; and 
if the buyer obligation has not been met and the 
option period has ended, determine an applica- 
ble buyer penalty based at least in part on a 



13 



25 



EP 1 361 531 A2 



penalty specified in the option contract. 



the offer to enter into the option contract com- 5 

prises a proposed term; and 

the negotiation module is operable to: 

access a memory comprising a range of 
acceptable contract terms; 10 
determine whether the proposed contract 
term is within the range of acceptable con- 
tract terms; 

if the proposed contract terms is within the 
range of acceptable contract terms, accept 1$ 
the proposed contract term without user in- 
put; and 

if the proposed contract terms is outside 
the range of acceptable contract terms, in- 
dicate that the proposed contract term re- 20 
quires user input. 

24. The supply manager of Claim 20, further comprising 
an aggregation module operable to: 

25 

compare a buyer aggregation of parameters 
with a seller aggregation of parameters; and 
modify at least one of the buyer or seller aggre- 
gations to more or less conform with a common 
aggregation of parameters. 30 

25. The supply manager of Claim 20: 

further comprising an option price module op- 
erable to: 35 

determine a proposed option price com- 
prising a cost of the proposed option to the 
seller; 

communicate the proposed option price to 40 
the buyer computer system; 

wherein the negotiation module is operable to 
negotiate with the seller computer system an 
agreed option price based on the value of the option 45 
to the buyer and a cost of the option to the seller. 



50 
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FIG. 4 P° 



TYPE; INCREMENTALLY EXERCISEO QUANTITY OPTIONS CONTRACT 
BUYING ENTERPRISE: 8 
SELLING ENTERPRISE: Y 
514 "^EXECUTION DATE: SEPT 5. 1999 
536 -n. EXERCISE PERIOD BEGIN: JAN 15. 2000 K 
538 "^EXERCISE PERIOD END: MAR 15. 2000 J W4 
51 6 DELIVERY DATE APRIL 1. 2000 
518 ./-SUPPLIER ITEM: WIDGET XYZ OF ENTERPRISE Y 
520-/- BUYER SITE: DALLAS DISTRIBUTION CENTER OF ENTERPRISE 8 
526 SLOWER QUANTITY LIMIT: 8000 \ 
528^ UPPER QUANTITY LIMIT: 10000 

524 ^PENALTIES FOR VIOLATION: fl/UNIT OF QUANTITY VIOLATION 
522-/- PRICE: J100/UNIT 
532 ^-OPTION PRICE: $5000 
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